home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 April: Mac OS SDK / Dev.CD Apr 97 SDK1.toast / Development Kits (Disc 1) / QuickDraw 3D / Samples / Cool Apps and Things!! / PatchDance v0.4b4 / Read Me Later < prev    next >
Encoding:
Text File  |  1996-05-21  |  7.7 KB  |  141 lines  |  [ttro/ttxt]
  1. PatchDance v0.4b4
  2.  
  3. Background information that may be interesting
  4.  
  5. Files:
  6.  - PatchDance’s native file format is designed for one purpose:  speed.  
  7.     Using a  number of techniques we have achieved one of the fastest 
  8.     save/load times in the  business.  The format is highly application-
  9.     specific and there are no plans to  document it.
  10.  - The (expected) downside is that files are relatively large.  A file
  11.     containing  roughly 9,000 entities of each type (point, spline, patch) should 
  12.     fit on a 1.4 MB  floppy.  The files compress fairly well (we’ve observed 
  13.     ~60% using Stuffit with small files.  This also writes to floppy faster 
  14.     than a direct Finder copy.)
  15.  - The new file format (v0.4b2 and later) is even faster and also supports 
  16.     merging files and creating libraries.
  17.  
  18. Future Directions
  19. Rendering:  This is under development.  Rendering per se is easy, fast ren
  20. dering is much harder, and writing enough shaders to support a practical 
  21. rendering engine is  very time consuming.  We are currently looking into 
  22. the following areas:
  23. 1. Adopt an existing shader type.  We currently plan to use the new Quick
  24.     Draw 3D specification.  This will allow importation of others’ shaders;  
  25.     export of ours will be limited to features that QuickDraw 3D supports.
  26. 2. Network rendering is possible and intended (eventually).  Currently we  
  27.     plan to license commercial networking software rather than develop 
  28.     our  own system.  The cost is extremely high and will have to passed 
  29.     along to users who want the feature.
  30.  
  31. Animation:  This will begin to be added in v0.5.  It will be possible to
  32. (automatically) save tweened frames individually for export.
  33.  
  34. Scheduled features:
  35.  - Full support for particle effects.  This will be implemented first  
  36.     (soon) in the Modeler, where it is a useful tool as well. 
  37.  - Physical effects.  Motion/acceleration graphs for paths (with preset  
  38.     gravity, etc.) will be supported.  Our graph method allows the use of a 
  39.     fully editable spline graph (with presets for gravity, etc) anywhere a 
  40.     number can be used.
  41.  - Collisions.  This allows triggering actions when a collision  is detected: 
  42.     i.e., when a vase hits the floor, the collision script divides it into 
  43.     pieces, activates particle effects, and causes the pieces  to tumble and 
  44.     fly apart.  And this will even be easy to set up!
  45.  - Inverse Kinematics.  This will be the final end of a detailed set of
  46.     motion constraints/object links.  No timetable.
  47.  - EVERYTHING will be animatable.  This includes all shader parameters  
  48.     (even blending of shaders, whether or not it makes sense) and any  
  49.     modeling operations that make sense at all (even Lathe and Extrude.)
  50.  
  51. Modeling:  The modeler will continue to get better and faster.  The Trim  
  52. function is a high priority but also a great challenge and we want it to  be 
  53. perfect, even if we aren’t the first to market with it.  (Though that still 
  54. looks likely at present.)
  55.  
  56. Scheduled additions:
  57.  - Particle effects.  For modeling, this applies to operations where it  
  58.     makes sense.  It will initially be implemented as an option for the 
  59.     Scale  and Rotate tools.  The animation version will add many more 
  60.     possibilities  and controls.
  61.  
  62. -  Nonlinear effects.  Examples are Bend, Twist, Taper, Bulge, Ripple,  etc.  
  63.     The Magnet Tool is a first generation effort:  useful but still  rough.  
  64.     Nonlinears are fashionable and not hard to implement;  we’ll be  happy 
  65.     to provide them if they’re demanded.  We have a few questions:
  66.  
  67.     1) Which are the most useful/desired?  Use the program a little before  
  68.     voting, since some effects (Shear) ARE supported and others (Bend, 
  69.     Taper)  are not hard to fake with existing tools.  We’re trying to 
  70.     avoid  redundancy or excessive numbers of specialized tools.
  71.  
  72.     2) What is a good interface?  These operations often have multiple  
  73.     variables, making them tricky to do interactively without arcane
  74.     numeric  options.  We currently don’t have a preferred method (conform 
  75.     object to  spline or “spine” techniques seem most feasible.)
  76.  
  77.  - MetaBalls.  This is difficult given the nature of the program, but  MB’s 
  78.     have enthusiastic support here.  When and if implemented, they may  
  79.     take two forms:
  80.  
  81.     1) Traditional.  This would be a new type of primitive (like a point or  
  82.     spline.)  All MB parameters will be adjustable and animatable with
  83.     out  limitation.  It will be possible (to some extent) to create a 
  84.     spline  mesh skin over a melted MB (no more export nightmares!)
  85.  
  86.     2) Blue Sky.  This highly speculative project involves applying the  
  87.     MetaBall effect to general objects (as a texture?)  Personally, I’m 
  88.     not sure this behavior can defined well enough to be useful, and 
  89.     PatchDance  objects also don’t remember their “original” shapes 
  90.     very well.  Don’t hold  your breath on this one.
  91.  
  92.  
  93. New Technology
  94. Will be added as it makes sense.  Major issues:
  95. - Multiple processors.  Based on preliminary data from Apple and DayStar,  
  96.     we expect good things from the new multiprocessor PowerMacs.  The 
  97.     time  frame for our implementation will depend on demand and the 
  98.     commercial success of the hardware.
  99.  - OpenDoc.  PatchDance is unlikely to be suitable as an OpenDoc part (for 
  100.     3D editing within an OpenDoc document), due to the  nature of our 
  101.     multi-window interface.  We are excited about the  possibility of
  102.     hijacking OpenDoc technology to provide high-quality image processing 
  103.     services from within PatchDance (experienced 3D users should be ex
  104.     cited about that too), but this will not be available any time soon.
  105.  - Copland (System 8).  This could have been designed just for us, and we  
  106.     expect it to significantly improve our performance and reliability (and  
  107.     make programming easier, as well).  It will be supported at the earliest  
  108.     possible moment.  If it works out well, PatchDance will quickly become 
  109.     a  System 8 only program.
  110.  
  111. Plugins.  (Programmers)
  112. PatchDance is designed to allow the use of plugin extensions.  These  will 
  113. be in the form of PowerPC shared libraries, allowing easy access to  our 
  114. public API with minimal use of callbacks.  Our technology also avoids the 
  115. common problem of incredibly slow extension loading at startup.   Current 
  116. design allows for several types:  General operations (Model menu func
  117. tions like Extrude);  Interactive (Tool Palette Tools -  it is  possible to 
  118. add new tools that are equivalent to ours, available from a  forthcoming 
  119. “Generic” button on the palette);  Animation (later);  Shaders  (later); and 
  120. file import/export (long term, hopefully QD3D will suffice.)  The Develop
  121. er Kit, when available, (don’t even ask) will include:  complete project 
  122. files for MetroWerks CodeWarrior C++;  precompiled headers including 
  123. tons of inlines;  and examples, including complete, buildable code for at 
  124. least one plugin of each type.
  125.  
  126. PatchDance Technology (Programmers)
  127. Some source code is available free for non-commercial use.
  128.  - A number of PowerPlant compatible control classes were developed for 
  129.     the program.  Source code is freely available, just e-mail Tech Support.  
  130.     Many are highly specialized and reflect PatchDance’s no-compromise,  
  131.     performance-first design (and may require some effort to adapt.)  They 
  132.     are supplied as-is, are poorly supported, and sometimes not too well 
  133.     documented.
  134.  - Requests for other source code/methods will be considered.  We try to  
  135.     always support non-competing and academic efforts, but we must also  
  136.     protect our technology.  Functions relating to the database engine,  
  137.     imaging system, and many modeling operations (especially on spline 
  138.     surfaces) are usually confidential.  If anything looks interesting, ask.
  139.  
  140.  
  141.